Implantable cardiac rhythm CRM devices, more specifically, cardiac defibrillators (ICDs) are well established therapeutic devices for treating patients who have experienced one or more documented episodes of hemodynamically significant ventricular tachycardia or ventricular fibrillation. Since their clinical inception more than two decades ago, ICDs have evolved from basic to sophisticated electronic devices that provide physicians with a variety of clinically useful functions with which to treat patients.
Presently, even the most basic ICDs typically have more than one tachycardia detection criterion, tiered therapy which combines bradycardia support pacing with various antitachycardia pacing modes, low-energy cardioversion, defibrillation, and data logging capabilities. The data logging capabilities within ICDs have become increasingly important, since the amount of data required for the ICDs operation increases proportionally with the increase in ICD functions. Efficiently processing this large amount of data has become possible with the incorporation of microprocessors and memory with the ICD.
Once an ICD has been implanted, the physician interacts with the ICD through a clinical programmer. The clinical programmer is used to establish a telemetric link with the implanted ICD. The telemetric link allows for instructions to be sent to the electronic circuitry of the ICD and clinical data regarding the occurrence and treatment of a patient's cardiac arrhythmias and the ICD's operation to be sent from the electronic circuitry of the ICD to the programmer. The typical programmer is a microprocessor based unit that has a wand for creating the telemetric link between the implanted ICD and the programmer, and a graphics display screen that presents a patient's recorded cardiac data and ICD system information to the physician.
As ICD feature sets become richer and more complex, ICDs are getting increasingly more complicated to program. This is especially the case in situations where modifications of one feature ripples through and interacts with other selected features.
For ICDs it can be very difficult for physicians to deal with non-compatibilities with programming. Such devices may have many features to program and, when physicians go in to program, there may be some inconsistencies that are not recommended by logic or by concerns for safety of the patient. In the past, these inconsistencies were displayed as error messages and the physician often had to wade through a series of screens to determine the nature of the inconsistency and how to resolve it.
In addition, physicians were frustrated by error messages, which note an interaction but did not tell them what to do resolve the problem. They were often reduced to trial and error programming which might create a second parameter interaction while resolving the first.
In addition, for devices currently on the market, device parameters are set by selecting from a list of possible options via the programmer. The options have typically been scattered throughout the programmer user interface.
What is needed is a more intuitive way for the physician to resolve parameter interactions and a user interface that allows related parameters to be displayed simultaneously to enhance physician resolution of such parameter interaction conflicts.